When web servers conduct transactions with each other, a very common programming pattern is to use HTTP as the transport. For example, a first server may issue an HTTP GET request to request a representation of a particular resource from a second server. The second server can, in turn, respond with the resource representation. Transactions between servers can also take place in a more asynchronous manner. For example, the first server may issue an HTTP GET request and provide a return URL for the second server to use in responding. At some later time, the second server can asynchronously return to the first server using the URL provided by the first server. This process can also easily operate in reverse between the servers.
Using this same model, transactions between client side applications, such as web browsers, and servers can operate with the client side application issuing an HTTP GET request and receiving a response from the server. Traditionally, though, servers cannot issue HTTP GET or POST requests to client side applications (e.g. a web browser) at least because client side applications are not able to act as web servers. Additionally, firewalls or other mechanisms such as Network Address Translation (NAT) devices interfere with traffic directed to clients making it difficult and/or impossible for web service like transactions to take place directly via client applications. While a proxy service can be used to provide some capabilities for client applications to act as web services, existing approaches are typically limited to providing short-lived and/or session-by-session addressing for such client applications. In this approach, each time a client starts a session a different address (e.g., URL) is assigned and the address changes between sessions. As a consequence, considerable time and processing resources are expended to set-up a client as a web service for each individual session and asynchronous transactions across multiple sessions may not be possible.